Typically disk drives are formatted physically and logically. Physically, a disk is divided into many equal-sized regions, such as sectors (pie slices) and tracks (concentric circles), so that data can be recorded in a logical manner and accessed quickly by read/write heads that move back and forth over the disk as it spins. Logically, a disk is formatted according to the standards of a host operating system.
To increase the storage efficiency of disk's they are generally defragmented. One approach to defragmentation is to use a DCOM utility of Hewlett Packard's NonStop Kernel operating system (NSK) that moves disk file extents to yield more usable space on a disk. The disk file extents are a collection of pages. Each page includes a block of data and/or a storage space on the disk. The DCOM utility first analyzes the current space allocation on a disk. The disk file extents on the disk are then relocated. Further, the free disk file extents are then combined into larger disk file extents so that files can be later allocated with larger disk file extents.
The above DCOM utility achieves the defragmentation by creating a temporary file for each source file that needs to copy the disk file extents. The DCOM utility then calls a file OPEN command for each temporary file, which is then implemented by the NSK. The NSK then allocates a new file control block (FCB) structure and a new open control block structure for this OPEN command. The DCOM utility then calls a COPY request for the source file, which then creates a FCB structure without opening the source file that allows the DCOM utility to defrag the source file in the background. The DCOM utility then removes the free disk file extents from a free space table attached to the temporary file and the disk file extent information is then stored in the FCB structure of the temporary file. The NSK then copies the disk file extent from the source file to the temporary file. The new disk file extent is then added to the file label of the source file and written to the disk when the disk file extent copy is completed. The old disk file extent is then added to the free space table in the disk.
When the DCOM utility copies the disk file extents to the temporary file, the number of disk file extents to be copied is more than a maximum input/output (I/O) value set in the NSK, such as a prefixed disk parameter (MAX_COPY_EXTENT) stored in the NSK, then the copy request will be redriven by the NSK. A redrive of a DCOM request can occur when the number of reads/writes to/from a disk exceeds a threshold value set in the NSK. In such an event, the NSK stores a value, thus far copied by the DCOM utility, in an offset field of a return buffer and sends it to the DCOM utility. The value stored in the offset field is a position value that is relative to the beginning of the file where the copying of the file starts after a redrive request. Further, in such a case, the DCOM utility has to again call back with the specified value stored in the offset field for the NSK to continue from the previously stored offset value. The NSK then stores the offset value in the source file control structure for a later use, such as a validation of the source file control structure.
One problem with the above-described DCOM utility process is for any reason the DCOM utility does not come back after the NSK redrives the COPY request, then the value stored in the offset field in the file control structure is not cleared. In such an instance, the NSK can close the temporary file that was opened by the DCOM utility. Since the source file was not opened by the DCOM utility the NSK cannot close the source file and therefore the FCB can be left stranded. Such a source file, that is left stranded, cannot be accessed for writing or purging by other applications. Further, such a condition can result in adverse effects. For example, a rerun of the DCOM utility cannot defrag that source file. Also, such a stranded file cannot be purged or renamed.